Sams Teach Yourself MCSE Windows NT Server 4 in 14 Days
(Publisher: Macmillan Computer Publishing)
Author(s): David Schaer, et al
ISBN: 0672311283
Publication Date: 12/15/97

Who was the last person to touch what isn’t working? This sounds like something a kid would say. However, knowing this can be invaluable. Usually, finding out who were the last people to work with a malfunctioning server can save you time in diagnosing the problem. They will know what they have done to it, which is better than you trying to guess what they did. And let’s face it, every network has at least one power user or administrator who knows just enough to be dangerous. Although they still are learning and can be an asset, they are at the stage that they also can be a liability.

These are just a few of the endless questions that you can ask yourself during the information-gathering phase of your troubleshooting process. The more facts you can collect, the closer you will be to solving the problem.

14.2.2. Formulating a Hypothesis

Troubleshooting is as much a science as it is an art. Any good scientist knows that before anything can be proven, a hypothesis must be formulated. My Webster’s dictionary defines a hypothesis as, “a theory that explains a set of facts and can be tested by further examination.”

So, you can see that the gathering of the facts in the previous step is necessary before you can hypothesize as to why a problem has occurred. With further investigation of the hypothesis, you can come to a conclusion about how to repair the problem.

This step is nothing more than taking the facts and making an educated guess about what caused the problem. The further testing comes next.

14.2.3. Testing and Documenting

The first part of this two-step phase is testing. Testing is taking your educated guess (hypothesis) and seeing whether it is correct. Your hypothesis is your judgment, based on the available evidence, of why the problem occurred. One way of testing is either reversing or attempting to repair the cause of the problem and then viewing the outcome.

Reversal is the undoing of what caused the problem. If the problem was in the setting of a configuration, then you should reset that configuration. If it was in the installation of something, then you should uninstall the program in question. Reversing a problem’s cause is putting the computer back to the state it was in before the problem occurred.

Because reversal is not always feasible (you cannot, for example, uninstall a program you need), repairing the problem usually is more viable. This might mean installing the latest patch from the manufacturer, for example. Repairing is not changing the computer back to a previous state; it is the negation of the cause’s negative effects.

During testing, you might change several things that do not resolve the problem. Be careful of domino situations, which are situations in which one thing has an effect on another, which in turn has an effect on something else, and so on. In most cases, when you are finished testing (and have resolved the problem), you will want to put the things that had nothing to do with the problem back to the way they were. Nothing is worse than resolving one problem only to create another.

The second part of this step is documentation. Documentation is something that most network administrators hate. However, it is a necessary evil. Documentation can help in several ways.

First, if you document what you do to the machine, you will have a better understanding of the problem should it arise again. Also, documentation can help others resolve a similar situation if they have access to the documentation but not to you. Finally, it can help you identify recurring problems with a particular server if you have an idea of what has gone wrong with it in the past.

14.3. Analyzing Boot Errors

Problems with Windows NT booting up can be the most frustrating troubleshooting cases you will have. If the server will not boot up, you not only are faced with a limited number of ways in which you can troubleshoot the machine, but you usually have a bunch of users breathing down your neck because they cannot access the server. You usually can attribute problems to one of the following:

•  Corrupt files

•  Missing files

•  Incorrect BOOT.INI

The first two situations can consist of several files. Other than the many DLL files necessary to get Windows NT up and running, common boot files also are necessary. These files are listed in Table 14.1.